The present invention relates to data processing systems, and more particularly, to a methodology and notation for identifying features on object-oriented object models that are fundamental or easily changeable.
This application is related in subject matter to the following applications filed concurrently herewith and assigned to a common assignee:
Application Ser. No. 08/993,718 filed by David Ehnebuske and Barbara McKee entitled, xe2x80x9cMethod and Apparatus For Identifying Applicable Business Rulesxe2x80x9d (IBM Docket AT9-97-503).
The foregoing co-pending applications are incorporated herein by reference.
One of the claims for object-oriented programming is that it makes it easier for software to model the real-life business situation. The new vision of computing is of distributed Business Objects existing as independently developed executables or binaries, which can be redeployed as self-contained units anywhere in a network, and on any platform. Powerful and flexible business processes and object modeling tools are evolving that give businesses and information technology (IT) specialists a common environment to define, redefine, model and automate business processes and reusable Business Objects. Businesses are finding, however, that encapsulating business logic into Business Objects provides insufficient flexibility and are moving towards externalizing business decisions into business rules which are described and manipulated by business experts instead of programmers.
Although the term Business Object has been in widespread use, no formal definition existed until the Object Management Group""s (OMG) Business Object Management Special Group (BOMSIG) took the task of developing a consensus meaning for the term. Business Objects are representations of the nature and behavior of real world things or concepts in terms that are meaningful to the business. Customers, products, orders, employees, trades, financial instruments, shipping containers and vehicles are all examples of real-world concepts or things that could be represented by Business Objects. Business Objects add value over other representations by providing a way of managing complexity, giving a higher level perspective, and packaging the essential characteristics of business concepts more completely. We can think of Business Objects as actors, role-players, or surrogates for the real world things or concepts that they represent.
Business Objects allow an enterprise to communicate, model, design, implement, distribute, evolve and market the software technology that will enable them to run their business. The characteristics of Business Objects include communication, modeling, design, implementation and distribution. Communication is provided through Business Objects which supply common terms and ideas at a level of detail which can be shared among business and technical people to articulate and understand the business in business terms. Modeling is achieved because Business Objects have certain characteristics and behaviors which enable them to be used naturally in modeling business processes, and the relationships and interactions between business concepts. The design characteristic is possible because Business Objects represent real world-things and concepts which enable the design effort to be concentrated in manageable chunks. Business Objects meet the implementation characteristic because they have late and flexible binding and well defined interfaces so that they can be implemented independently. Finally, distribution is possible because Business Objects are independent so that they can be distributed as self-contained units to platforms with suitable installed infrastructure.
Many business problems are analyzed, designed and documented using an object-oriented modeling notation. The notations in the popular methodologies do a good job of capturing the business operations between Business Objects. Using one of these modeling notation, developers build interface object models, local Business Object models, corporate Business Object models, and storage object models.
An object model is used to describe objects in a system and their relationships. It describes the system, classes, attributes, operations, and relationships in and among the object entities in the system. Each object-oriented entity becomes a class in a class diagram which depicts a graph whose nodes denote object classes and whose arcs denote relationships between classes. In the object model, object identifiers, their attributes, and their methods are described. The object model provides a framework in which the dynamic and the functional models are represented.
Many businesses are finding that they frequently need to quickly change their computing systems as their business needs change. One of the principal goals of doing object-oriented analysis and design for business applications is to structure the Business Object model in such a way as to make this sort of business-driven change quick and easy by business experts instead of programmers. Unfortunately, object models described using popular notations are not explicit about what sorts of changes the object modelers anticipated and what sorts they did not. This creates problems because object modelers are often not clear about which anticipated business changes are accounted for in the model, and it is not clear to those who later must change the model how best to accommodate business-driven changes.
Consequently, it would be desirable to provide a methodology and notation to the object modeling notations to explicitly distinguish those features of the object-oriented object models that are intended to be easily changeable due to changing business needs from those features which are fundamental to the model.
This invention relates to a method and apparatus for providing a methodology and notation which enables the Object Modeling Technique static object model to explicitly distinguish those features of an object-oriented object model that are intended to be easily changed due to changing business needs, from those features which are fundamental to the object models. The methodology does this during the modeling process by capturing decisions to allow for business-driven variability as explicit diagram annotations called Control Points. The business variable portions of the system of interacting objects are simultaneously captured as objects called Business Rules.